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Status of this Memo 
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Abstract 


Layer Two Tunneling Protocol (L2TP) describes a mechanism to tunnel 
Point-to-Point (PPP) sessions. The protocol has been designed to be 
independent of the media it runs over. The base specification 
describes how it should be implemented to run over the User Datagram 
Protocol (UDP) and the Internet Protocol (IP). This document 
describes how L2TP is implemented over Frame Relay Permanent Virtual 
Circuits (PVCs) and Switched Virtual Circuits (SVCs). 


Applicability 


This specification is intended for those implementations which desire 
to use facilities which are defined for L2TP and applies only to the 
use of Frame Relay pont-to-point circuits. 


1.0 Introduction 


L2TP [1] defines a general purpose mechanism for tunneling PPP over 
various media. By design, it insulates L2TP operation from the 
details of the media over which it operates. The base protocol 
Specification illustrates how L2TP may be used in IP environments. 
This document specifies the encapsulation of L2TP over native Frame 
Relay and addresses relevant issues. 
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2.0 Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [2]. 


3.0 Problem Space Overview 


In this section we describe in high level terms the scope of the 
problem being addressed. Topology: 


4------ + 4--------------- + | 
| PSTN | | Frame Relay | 

User--| |----LAC === |=== LNS --+ LANs 
| ISDN | | Cloud | | 
4------ + 4--------------- + | 


An L2TP Access Concentrator (LAC) is a device attached to the 
Switched network fabric (e.g., PSTN or ISDN) or co-located with a PPP 
end system capable of handling the L2TP protocol. The LAC need only 
implement the media over which L2TP is to operate to pass traffic to 
one or more LNS’s. It may tunnel any protocol carried within PPP. 


L2TP Network Server (LNS) operates on any platform capable of PPP 
termination. The LNS handles the server side of the L2TP protocol. 
L2TP is connection-oriented. The LNS and LAC maintain state for each 
user that is attached to an LAC. A session is created when an end- 
to-end PPP connection is attempted between a user and the LNS. The 
datagrams related to a session are sent over the tunnel between the 
LAC and LNS. A tunnel is defined by an LNS-LAC pair. The tunnel 
carries PPP datagrams between the LAC and the LNS. 


L2TP protocol operates at a level above the particular media over 


which it is carried. However, some details of its connection to 
media are required to permit interoperable implementations.  L2TP 
over IP/UDP is described in the base L2TP specification [1]. Issues 


related to L2TP over Frame Relay are addressed in later sections of 
this document. 


4.0 Encapsulation and Packet Format 


L2TP MUST be able to share a Frame Relay virtual circuit (VC) with 
other protocols carried over the same VC. The Frame Relay header 
format for data packet needs to be defined to identify the protocol 
being carried in the packets. The Frame Relay network may not 
understand these formats. 
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All protocols over this circuit MUST encapsulate their packets within 
a Q.922 frame. Additionally, frames must contain information 
necessary to identify the protocol carried within the frame relay 
Protocol Data Unit (PDU), thus allowing the receiver to properly 
process the incoming packet. 


The frame format for L2TP MUST be SNAP encapsulation as defined in 
RFC 1490 [6] and FRF3.1 [3]. SNAP format uses NLPID followed by 
Organizationally Unique Identifier and a PID. 


NLPID 


The single octet identifier provides a mechanism to allow easy 
protocol identification. For L2TP NLPID value 0x80 is used which 
indicates the presence of SNAP header. 


OUI & PID 


The three-octet Organizationally Unique Identifier (OUI) 0x00-00-5E 
identifies IANA who administers the meaning of the Protocol 
Identifier (PID) 0x0007. Together they identify a distinct protocol. 


Format of L2TP frames encapsulated in Frame Relay is given in Figure 
1. 


Octet 1 
Q. L 2-3 .4-5.6 I Be 9 Ql '2:3.:4-5 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


1 | Q.922 Address 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
3 | Control 0x03 | pad 0 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
5 | NLPID 0x80 | OUI 0x00 | 
+-+-+-+-+-+-+-+-+ + 
7 | OUI 0x00-5E | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
9 | PID 0x0007 | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


L2TP packet 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| FCS | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1 Format for L2TP frames encapsulated in 
Frame Relay 
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5.0 MTU Considerations 


FRF.12 [5] is the Frame Relay Fragmentation Implementation Agreement. 
If fragmentation is not supported, the two Frame Relay endpoints MUST 
support an MTU size of at least 1526 which is based on adding the PPP 
Max-Receive-Unit size with the PPP header size with the Max L2TP 
Header Size with the Frame Relay header size (PPP header size is the 
protocol field size plus HDLC framing bytes, which is required by 
L2TP). To avoid packet discards on the Frame Relay interface, the 
RECOMMENDED default Frame Relay MTU is 1564 based on a PPP default 
MRU of 1500. The means to ensure these MTU settings are left to 
implementation. 


6.0 QOS Issues 


In general, QoS mechanisms can be roughly provided for with 
proprietary mechanisms localized within the LAC or LNS. QoS 
considerations are beyond the scope of this document. 


7.0 Frame Relay and L2TP Interaction 


In case of Frame Relay SVCs, connection setup will be triggered when 
L2TP tries to create a tunnel. Details of triggering mechanism are 
left to implementation. There SHALL NOT be any change in Frame Relay 
SVC signaling due to L2TP. The endpoints of the L2TP tunnel MUST be 
identified by X.121/E.164 addresses in case of Frame Relay SVC. 
These addresses MAY be obtained as tunnel endpoints for a user as 
defined in [4]. In case of PVCs, the Virtual Circuit to carry L2TP 
traffic MAY be configured administratively. The endpoints of the 
tunnel MUST be identified by DLCI, assigned to the PVC at 
configuration time. This DLCI MAY be obtained as tunnel endpoints 
for a user as defined in [4]. 


There SHALL be no framing issues between PPP and Frame Relay. PPP 
frames received by LAC from remote user are stripped of CRC, link 
framing, and transparency bytes, encapsulated in L2TP, and forwarded 
over Frame Relay tunnel. 


8.0 Security Considerations 


Currently there is no standard specification for Frame Relay security 
although the Frame Relay Forum is working on a Frame Relay Privacy 


Agreement. In light of this work, the issue of security will be re- 
examined at a later date to see if L2TP over Frame Relay specific 
protection mechanisms are still required. In the interim, basic 


security issues are discussed in the base L2TP specification [1]. 
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12.0 Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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